Purpose

This tool mentor tells how to view the history of a requirement in Rational RequisitePro.

Rational Unified Process Related Steps:

In the Configuration & Change Management Workflow:

Overview

As requirements are modified, the requirement history allows you to keep track of the what, when, why and who of these actions. Requirement history provides powerful information such as:

  • How often your requirements change (too much change too quickly may be indicative of an ill-defined requirement).
  • Who modified a particular requirement (so that you can consult that person and understand his/her motives before validating or invalidating that change).
  • Why a requirement has changed (rationale).
  • What caused a relationship between two requirements to become "suspect".

The history of a requirement is particularly useful during impact analysis to decide whether a requirement change has an impact on requirements it is linked to. This Tool Mentor introduces the following requirement history procedures:

  1. Viewing the history of a requirement
  2. Performing impact analysis
  3. Tips on successfully recording the history of requirements

1. Viewing the History of a Requirement To top of page

The history of a requirement in RequisitePro is located in the Revision tab of the Requirement Properties dialog box. This dialog box is accessible from either the Word Workplace or the Views Workplace.

In the Word Workplace:

  1. In a requirements document, position your cursor in the text of a requirement.
  2. Select Requirement > Properties from the RequisitePro Tool Palette or select RequisitePro > Requirement > Properties in the Word Workplace. The Requirement Properties dialog box appears.

In the Views Workplace:

  1. While in a view, select the requirement row and right-click to display the context-sensitive menu.
  2. Select Properties from the pop-up menu. The Requirement Properties dialog box appears.

At the Requirement dialog box:

  1. Click the Revision tab. This pane displays the last change made to that requirement. The date, time, author and change description (rationale for the change) are shown.
  2. Click the History button. The Revision History dialog box displays all modifications made to that requirement from the time it was created. RequisitePro automatically increases the Revision number as modifications occur.
  3. Click on a revision in the revisions list box to view details about that revision.
  4. Click Print to print the set of revisions for that requirement.

Note: If you need to simultaneously print revisions pertaining to multiple requirements, use Rational SoDA, the Rational document automation tool, to extract any set of revisions from the RequisitePro repository and print a Microsoft Word or Adobe FrameMaker document. Alternatively, open the read-only RequisitePro database via an ODBC connection and use an off-the-shelf report to query revisions on multiple requirements.

2. Perform Impact Analysis To top of page

Reviewing the history of a requirement is an important step in impact analysis. One of the purposes of setting traceability links between requirements is to measure the impact of a requirement change on related requirements.

RequisitePro displays impact of requirement modifications with a suspect link. A suspect link is visually represented in a traceability matrix or a traceability tree with a red slash over a traceability arrow. This indicator visually notifies users that a requirement has changed (its text or one of its attributes) and that there is possible impact on requirements that are traced to or from the modified requirement.

When a suspect link is displayed, a designated person on the project (typically the project manager) investigates what caused the suspect link and how much impact it may have on other requirements. This designated person views the history of the two requirements involved in the suspect link, following the steps outlined in the above section on Viewing the History of a Requirement. When viewing the history of the modified requirement, two decisions can be made:

  • The modification to that requirement has no impact on the linked requirements. In this case, the suspect link can be cleared. To clear a suspect link, while in a traceability view, position your cursor on the suspect link icon. Right-click to display the context-sensitive menu, and select Clear Suspect.
  • The modification has an impact on the linked requirements. In this case, the definition of the linked requirement(s) needs to be updated to reflect the change before the link is cleared:
  1. While in a traceability view, double-click on the requirement that is affected. If the requirement was created in a RequisitePro document, RequisitePro opens the document and positions the cursor on the requirement.
  2. Modify the text of the requirement to reflect the impact of the related requirement.
  3. Click Document > Save to commit your change. If the requirement was created directly in a view, the Requirement dialog appears.
  4. Modify the Text field, and click OK to commit your change.

3. Tips on Successfully Recording the History of Requirements To top of page

The following are useful tips related to the use of requirements history.

Tip 1: Assign usernames to all users

An important record in the requirement history is the author of the requirement change. This author is the user logged into the RequisitePro project at the time the requirement is modified. In order to record which user logs in, you need to enable the RequisitePro project security.

By default, RequisitePro projects have security disabled. Even if you do not want to set permissions for each project components (project, documents, requirements, etc.), enabling security allows you to assign user names to users. These user names will be entered in the requirement revisions as a user creates or modifies a requirement.

To enable security and create user names, do the following:

  1. At the Tool Palette, select Project > Security. The Project Security dialog box appears.
  2. Mark the "Enable security for this project" check box.

(Optionally) Create user groups:

  1. Click on the Add button located in the Groups box (on left side of the Project Security dialog box). The Group Permissions dialog box appears.
  2. Enter a group name and define permissions for that group. Permissions can be set for specific document types, requirement types, attributes, and attribute values. You can also define whether this group of users can modify the project structure. This can include permission to add attributes to requirement types, add document types, etc.

To add an individual user:

  1. Select a group in the Groups list in the Project Security dialog box.
  2. Click the Add button located in the "Users of Group" box. The Add User dialog box appears.
  3. Enter a Username (ex: John Smith).
  4. Optionally, enter a password and e-mail address. E-mail addresses are used when users participate in email-enabled group discussions.
Tip 2: Do not delete requirements

RequisitePro allows you to delete requirements. This feature is useful when you first create a project; you may want to experiment with how to use RequisitePro and what level of detail you want to use for requirements. At some point, you will decide that your project is now ready to be maintained. From that point on, you should keep track of every modification made in the project. If you delete a requirement, be aware that when RequisitePro deletes requirements, every property of that requirement is deleted, including its history; this is typically information you do not want to lose. RequisitePro requires your confirmation before deleting the requirement. Rather than deleting a requirement using the Delete feature, we recommend you follow these steps:

  1. Create an attribute (ex: Deleted, or Inactive) to mark requirements as "deleted" (or inactive). You can re-activate that requirement later by simply changing the value of that attribute.
  2. You might also want to relocate inactive requirements either to the bottom of their document, or to the database (so that inactive requirements donÆt appear in documents). To relocate document-based requirements (which are requirements that are created in the Word Workplace rather than in the View Workplace), follow these steps:
  3. In the Word Workplace, position your cursor in the requirement text.
  4. On the Tool Palette, select Requirement > Cut, or in the Word Workplace, select RequisitePro > Requirement > Cut.
  5. On the Tool Palette, click the "Switch to the views workplace" icon to go to the Views Workplace.
  6. Create an attribute view, then select Requirement > Paste in the Views Workplace Requirement menu.
Tip 3: Add revisions to traceability relationships

By default, RequisitePro maintain revisions of requirements, not traceability links. To set RequisitePro to also maintain revisions of traceability links:

  1. At the RequisitePro Tool Palette, click Tools > Options.
  2. In the Traceability section, mark the check box "Changes logged in history."
  3. Click OK.
  4. To verify the traceability history log, open a traceability matrix in the Views Workplace. Add or remove a traceability link between two requirements. Double-click on one of the requirements to open the Requirement dialog box. At the Revision tab, click History. The traceability change appears in the Revision list.
Tip 4: Always fill in change notification dialogs

Good requirement management process recommends that a project member records the reason why a requirement is changed. RequisitePro provides a Change Description field to record this information.

The Change Description field is located on the Revision tab of the Requirement Properties dialog box.

Also, when saving a RequisitePro document containing requirements that have been modified, RequisitePro displays the Change Notification dialog box for each modified requirement. You can use the "Apply to all modified requirements in the document" check box to attach the same Change Description information to all modified requirements (ex: "per meeting with VP on 7/3/98").

It is very important to input a meaningful description in the Change Description field, so that every requirement modification is fully captured in the requirement history.

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process